What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2021-11-05 13:07:47 | Topic-specific policies 12/11: concluding the series (lien direct) |  Congratulations on completing this cook's tour of the topic-specific information security policies in ISO/IEC 27002:2022 (forthcoming). Today we reach the end of the track, reflecting back on our journey and gazing forward to the next objective.Through the blog, we have stepped through the eleven topic-specific policy examples called out in clause 5.1, discussing various policy-related matters along the way: 0. Introduction: an initial overview of the classical 'policy pyramid'. 1. Access control: 'policy axioms' are key principles underpinning policies. 2. Physical and environmental security: ignore these aspects at your peril!3. Asset management: using templates/models to develop your policies.4. Information transfer: consider the business context for policies. 5. Networking security: risks associated with data and social networks.6. Information security incident management: unique or general?7. Backup: there's more to information risk management than cyber! 8. Cryptography and key management: important for |
APT 17 | ||
|
2021-10-20 16:00:00 | Topic-specific policy 8/11: cryptography and key management (lien direct) | Maybe this particular policy was mentioned in previous editions of ISO/IEC 27002 and picked as a topic-specific policy example for the forthcoming 3rd edition in order to include something directly relevant to governmental organisations, although to be fair crypto is a consideration for all of us these days. Many (most?) websites are now using HTTPS with TLS for encryption, for example, while cryptographic methods are commonly used for file and message integrity checks, such as application/patch installers that integrity-check themselves before proceeding, and password hashing.Here's a glimpse of one I prepared earlier: Like all our templates, this one is generic. Organisations with specific legal or contractual obligations in this area (such as governmental and defense companies bound to employ particular algorithms, key lengths and technologies such as physically secure hardware crypto modules, or companies bound by PCI-DSS) would need to adapt it accordingly. You'll see that it mentions the Information Classification Policy: I'll have more to blog about classification tomorrow.If you've been tagging along on my tiki-tour of the topic-specific policy examples in ISO/IEC 27002:2022, and if you read that LinkeDin piece by Chris Hall that I recommended, you will probably by now recognise the standard document structure we've adopted for all our policy templates. The main elements are:Page header with a logo (our logo in the template, yours to download and customise) and a short, pithy, catchy policy title.Information security policy up-front to be crystal clear about the nature and ownership of the policy, since some topics could equally belong to other corporate functions (e.g. our "Fraud" policy template is, in fact, an information security policy addressing the information risks associated with fraud, misrepresentation and so on, not an HR or legal policy about disciplinary procedures and compliance). Policy title, big and bold to stand out. The precise wording is important here (I'll return to that point in another blog piece).Policy summary, outlining |
APT 17 | ||
|
2021-10-15 12:40:00 | Topic-specific policy 4/11: information transfer (lien direct) |  "Information transfer" is another ambiguous, potentially misleading title for a policy, even if it includes "information security". Depending on the context and the reader's understanding, it might mean or imply a security policy concerning:Any passage of information between any two or more end points - network datacommunications, for instance, sending someone a letter, speaking to them or drawing them a picture, body language, discussing business or personal matters, voyeurism, surveillance and spying etc.One way flows or a mutual, bilateral or multilateral exchange of information.Formal business reporting between the organisation and some third party, such as the external auditors, stockholders, banks or authorities.Discrete batch-mode data transfers (e.g. sending backup or archival tapes to a safe store, or updating secret keys in distributed hardware security modules), routine/regular/frequent transfers (e.g. strings of network packets), sporadic/exceptional/one-off transfers (e.g. subject access requests for personal information) or whatever. Transmission of information through broadcasting, training and awareness activities, reporting, policies, documentation, seminars, publications, blogs etc., plus its reception and comprehension. Internal communications within the organisation, for example between different business units, departments, teams and/or individuals, or between layers in the management hierarchy."Official"/mandatory, formalised disclosures to authorities or other third parties.Informal/unintended or formal/intentional communications that reveal or disclose sensitive information (raising confidentiality concerns) or critical information (with integrity and availability aspects). Formal provision of valuable information, for instance when a client discusses a case with a lawyer, accountant, auditor or some other professional. Legal transfer of information ownership, copyright etc. between parties, for example when a company takes over another or licenses its intellectual property.Again there are contextual ramifications. The nature and importance of information transfers differ between, say, hospitals and health service providers, consultants and their clients, social media companies and their customers, and battalion HQ with operating units out in the field. There is a common factor, however, namely information risk. The in |
General Information Guideline | APT 17 | |
|
2021-10-14 17:20:00 | Topic-specific policy 3/11: asset management (lien direct) |  This piece is different to the others in this blog series. I'm seizing the opportunity to explain the thinking behind, and the steps involved in researching and drafting, an information security policy through a worked example. This is about the policy development process, more than the asset management policy per se. One reason is that, despite having written numerous policies on other topics in the same general area, we hadn't appreciated the value of an asset management policy, as such, even allowing for the ambiguous title of the example given in the current draft of ISO/IEC 27002:2022. The standard formally but (in my opinion) misleadingly defines asset as 'anything that has value to the organization', with an unhelpful note distinguishing primary from supporting assets. By literal substitution, 'anything that has value to the organization management' is the third example information security policy topic in section 5.1 ... but what does that actually mean?Hmmmm. Isn't it tautologous? Does anything not of value even require management? Is the final word in 'anything that has value to the organization management' a noun or verb i.e. does the policy concern the management of organizational assets, or is it about securing organizational assets that are valuable to its managers; or both, or something else entirely? Well, OK then, perhaps the standard is suggesting a policy on the information security aspects involved in managing information assets, by which I mean both the intangible information content and (as applicable) the physical storage media and processing/communications systems such as hard drives and computer networks?Seeking inspiration, Googling 'information security asset management policy' found me a policy by Sefton Council along those lines: with about 4 full pages of content, it covers security aspects of both the information content and IT systems, more specifically information ownership, valuation and acceptable use:1.2. Policy Statement The purpose of this policy is to achieve and maintain appropriate protection of organisational assets. It does this by ensuring that every information asset has an owner and that the nature and value of each asset is fully understood. It also ensures that the boundaries of acceptable use are clearly defined for anyone that has access to |
Tool Guideline | APT 17 | |
|
2021-10-12 19:44:00 | Topic-specific policy 1/11: access control (lien direct) | Clause 5.1 of the forthcoming new 2022 edition of ISO/IEC 27002 recommends having a topic-specific information security policy on "access control". OK, fine, so what would that actually look like, in practice?Before reading on, think about that for a moment. Imagine if you were tasked to draft an access control policy, what would it cover? What form would it take?How would you even start? How about something along these lines, for starters: What is access control intended to achieve? In about half a page, the background section explains the rationale for controlling access to assets (meaning valuable things such as information in various forms, including but more than just digital data).The policy goes on to state that, whereas access to information should be restricted where necessary, access by workers should be permitted by default unless there are legitimate reasons to restrict it. In other words, a liberal approach that releases information for use unless it needs to be restricted for some reason ... which in turn begs questions about what are those legitimate reasons? Who decides and on what basis?The alternative approach is to restrict access to assets by default unless there sound reasons to permit access, begging the same questions.The template policy takes both approaches, in the form of these complementary 'policy axioms':Policy axioms (guiding principles) [if !supportLists]-->A. Access to corporate information assets by workers should be permitted by default unless there is a legitimate need to restrict it. [if !supportLists]-->B. Access to corporate information assets by third-parties should be restricted by default unless there is a legitimate need to permit it. The idea is that, generally speaking, "workers" (which is defined elsewhere to include employees on the organization's payroll - staff and managers - plus third party employees and others such as interns, temps and consultants working for and on behalf of the organisation, under its co |
APT 17 | ||
|
2019-12-22 13:14:31 | NBlog Dec 22 - zero-based risk assessment (lien direct) |  In a thread on the ISO27k Forum, Ed Hodgson said:"There are many security controls we have already implemented that already manage risk to an acceptable level e.g. my building has a roof which helps ensure my papers don't get wet, soggy and illegible. But I don't tend to include the risk of papers getting damaged by rain in my risk assessment".Should we consider or ignore our existing information security controls when assessing information risks for an ISO27k ISMS? That question took me back to the origins of ISO27k, pre-BS7799 even. As I recall, Donn Parker originally suggested a standard laying out typical or commonplace controls providing a security baseline, a generally-applicable foundation or bedrock of basic or fundamental controls. The idea was to bypass the trivial justification for baseline controls: simply get on with implementing them, saving thinking-time and brain-power to consider the need for additional controls where the baseline controls are insufficient to mitigate the risks. [I'm hazy on the details now: that was ~30 years ago after all.]I have previous used and still have a soft-spot for the baseline concept … and yet it's no easier to define a generic baseline today than it was way back then. In deciding how to go about information risk analysis, should we:Go right back to basics and assume there are no controls at |
APT 17 |
1
We have: 6 articles.
We have: 6 articles.
To see everything:
Our RSS (filtrered)
